Day18 結尾留了一句話：「Day19 要把這些累積下來的指令實際串起來，跑一次
/refine-inbox、/new-adr完整銜接的整合 demo，驗證 Stage 3 整段流程真的能無縫接軌。」Day15 驗證/refine-inbox的分類與 Frontmatter 補齊、Day16 補上自動織入雙向連結、Day17 驗證/new-adr的三段式正文生成、Day18 把 Agent 呼叫brain-cli的方式寫成契約——這四次驗證都刻意收斂到一到兩篇草稿的最小規模，各自證明了「這個功能本身是對的」，但從來沒有人在同一個操作序列裡驗證「一批內容各異的草稿」「跨筆記自動織入」「緊接著再跑一次/new-adr」疊在一起會不會出問題。
Stage 3（Day13-19）在進入 Day20 的 Graphify 知識圖譜階段之前，需要收這個尾。今天不重新驗證任何指令的內部邏輯，而是驗證這些邏輯疊起來之後，銜接處是不是真的順。
Day15-18 的測試草稿多是「隨手寫一篇」，這次刻意反過來設計：先把 CLAUDE.md 定義的四條 PARA 判斷問題（有無明確截止日期、是否長期主動維護、是否被動查閱、是否已結案）各準備一篇對應的草稿，再加一篇語意刻意模糊、不對應任何一條問題的草稿，用來驗證「內容不足以判斷歸屬時保留在 00_Inbox」這個 Day15 就已定義的既有行為（這不是本次新增的驗證重點，只是確認批次規模下這個既有行為沒有被破壞）。
五篇草稿的內容與預期歸屬：
| 草稿標題 | 關鍵特徵 | 預期歸屬 |
|---|---|---|
| Graphify 匯出格式規劃 | 明確寫出 9/15 deadline，且已列出具體待完成項目 | 10_Projects |
| Graphify 資料模型與 brain-cli 索引對應關係 | 沒有截止日期，但需要隨 internal/vault.BuildIndex 演進持續維護 |
20_Areas |
| Obsidian Wikilink 語法備忘 | 被動查閱、不需主動維護 | 30_Resources |
| Day12 效能 benchmark 草稿（已完成） | 已完成且已封存，只作留存記錄 | 40_Archives |
| 零散想法 | 內容語意不足以對應任何一條判斷問題 | 保留在 00_Inbox |
其中前兩篇（Graphify 匯出格式規劃、Graphify 資料模型與 brain-cli 索引對應關係）刻意共享 tags: ["graphify"]，這是設計上的關鍵：Day16 的自動織入邏輯是依共享 tag 找候選筆記，但兩篇都還是 type: inbox-draft 時，自動織入不會處理草稿狀態的筆記——只有在批次處理把兩篇都轉成正式筆記之後，才有機會彼此觸發。這正好可以驗證「單次批次呼叫內部依序處理多篇、且跨筆記狀態依賴確實在同一次操作序列裡正確發生」，而不只是巧合對到一篇。
草稿內容全部人工撰寫，不用程式產生器——這次要驗證的是「內容多樣性導致的分類判斷」，需要語意上真的對應 CLAUDE.md 判斷問題的草稿，這種語意設計沒辦法用決定性生成規則產生。數量也控制在「四種歸屬 + 一篇無法判斷 + 一組跨筆記共享 tag」所需的最小集合，不為了規模感而多加筆記（這跟 Day12 效能 benchmark 需要上千篇合成筆記的取捨方向正好相反）。
準備好之後先跑一次 brain scan --json 確認五篇草稿的目標搬移路徑都不與既有筆記檔名衝突，避免示範過程中把 Day15 既有的檔名衝突處理行為誤認成本次發現的新問題。
/refine-inbox 批次執行結果：四種歸屬全部落地，跨筆記織連結確實觸發對 vault/00_Inbox/ 執行一次未帶檔名參數的 /refine-inbox，讓 Agent 依檔名排序一次讀取並處理全部草稿。實際搬移結果與預期完全一致：
Graphify 匯出格式規劃 → vault/10_Projects/，type 補為 atomic-note、status 補為 growing
Graphify 資料模型與 brain-cli 索引對應關係 → vault/20_Areas/
Obsidian Wikilink 語法備忘 → vault/30_Resources/
Day12 效能 benchmark 草稿（已完成） → vault/40_Archives/
零散想法 保留在 vault/00_Inbox/，type 仍是 inbox-draft
跨筆記自動織入雙向連結確實在批次處理中觸發：兩篇共享 graphify tag 的筆記，正文都各自補上了 ## Related 區塊，互相指向對方：
# Graphify 匯出格式規劃
...
## Related
- [[Graphify 資料模型與 brain-cli 索引對應關係]]
# Graphify 資料模型與 brain-cli 索引對應關係
...
## Related
- [[Graphify 匯出格式規劃]]
這組雙向連結是批次處理過程中才成立的——兩篇草稿還沒完成搬移、狀態還是 inbox-draft 時彼此不會被自動織入看見，只有在單次呼叫內部依序處理完兩篇、都轉為 atomic-note 之後，才會被 Day16 的織入邏輯抓到彼此。批次處理完成後執行 brain health --json，確認完全沒有因為這次批次搬移新增任何斷鏈：
{"orphanCount": 8, "brokenLinkCount": 0, ...}
brokenLinkCount 維持 0。孤立筆記清單裡的 8 篇（包含 零散想法、剛搬移的 Obsidian Wikilink 語法備忘、Day12 效能 benchmark 草稿（已完成） 等）都能個別解釋——零散想法 是刻意留下的無法判斷案例，其餘幾篇本質上就是沒有共享 tag、也沒有其他筆記引用的獨立參考資料，孤立狀態符合預期，不是批次處理引入的缺陷。
/new-adr 銜接：接在剛異動完的 vault 狀態之後，不是另起一次獨立操作批次處理過程中浮現一個值得記錄的技術決策：為什麼選擇一次呼叫處理整批草稿，而不是逐篇分別呼叫 /refine-inbox 六次？緊接著批次處理之後，執行一次 /new-adr 為何一次處理整批草稿而非逐篇呼叫 refine-inbox。
新筆記正確建立於 vault/30_Resources/，Frontmatter 固定規則符合既有規範：
id: 20260820-091500
title: 為何一次處理整批草稿而非逐篇呼叫 refine-inbox
type: adr
status: evergreen
tags: ["refine-inbox", "batch-processing"]
三段正文（背景、決策、後果）都有實質內容，沒有「待補充」的空白段落——決策內容明確記錄了「跨筆記狀態依賴必須在同一次操作序列裡驗證，逐篇呼叫雖然能達成同樣的最終織入結果，但無法驗證這件事本身」這個 Day19 示範的核心動機。
關鍵是這次 /new-adr 的自動織入與健康檢查，確實接在 /refine-inbox 剛異動完的 vault 狀態之後運作，而非各自獨立的兩次操作：這篇新 ADR 沒有與剛搬移的任何一篇共享 tag，所以自動織入沒有幫它加上 ## Related 連結，這是預期內、正確的行為——不是因為銜接失敗而漏做，是因為織入的觸發條件（共享 tag）本來就沒有成立。緊接著再跑一次 brain scan --json／brain health --json，確認新增這篇 ADR 之後筆記總數正確累加為 14 篇（原本 13 篇加上這篇新 ADR），斷鏈數依然是 0，沒有出現跟批次處理結果衝突或互相覆蓋的痕跡。
比照 Day12（Stage 2 收尾）的做法：只在文章裡敘述「示範成功了」，缺少可回頭查驗的契約——往後如果有人調整 /refine-inbox 的批次處理邏輯，沒有任何 Requirement 能告訴他「批次規模、跨筆記織連結、健康度」這三者必須同時成立。所以這次示範驗證到的場景，寫成 refine-inbox-workflow 的新 Requirement：「單次未帶參數呼叫需能正確處理涵蓋全部四種 PARA 歸屬、含跨筆記自動織入雙向連結的批次草稿，且完成後 brain health 不因此新增斷鏈」，讓它成為明確、可回頭驗收的標準，而不是一次性的示範記錄。
這則 Requirement 加在既有的 refine-inbox-workflow capability 底下，不是新開一個 capability——批次規模加跨筆記織連結本質上還是 Day15 批次處理、Day16 自動織入這兩個既有能力在更大場景下的驗收擴充。/new-adr 這次也被實際執行，但驗證下來它接在 /refine-inbox 之後的行為完全落在 Day17 既有 Requirement 的範疇內，沒有發現需要新增或修改的契約缺口，agent-workflow-adr spec 不需要異動。
驗證方式延續 Day15-17 的一貫作法：人工比對 slash command 的輸出摘要與 brain scan --json／brain health --json 的結果，不引入自動化整合測試框架去斷言 Agent 的分類決策。理由沒有變——/refine-inbox、/new-adr 的核心行為本來就是靠 Claude Agent 的自然語言理解與工具呼叫完成，分類判斷、正文生成這些步驟不是決定性程式邏輯，沒辦法用單元測試斷言「這次一定會分類到 10_Projects」。這次只是把驗證範圍從「單篇」擴大到「批次 + 跨指令銜接」，驗證手段本身沒有改變：把預期結果（四種歸屬各自落地、跨筆記織連結確實觸發、健康度不劣化）寫清楚，再實際跑一次去對照，即使驗證動作是人工的，驗收標準本身依然是明確、可重複檢查的。
Stage 3（Day13-19）到這裡收尾：Day13-14 建立了 Claude Code Agent 的執行機制與 CLAUDE.md 規範基礎，Day15-16 讓 /refine-inbox 具備分類、Frontmatter 補齊與自動織入雙向連結的能力，Day17 的 /new-adr 補上了決策記錄的產出方式，Day18 把 Agent 呼叫 brain-cli 的方式第一次寫成明確契約。今天的整合示範證明了這些能力不只是各自正確，疊起來、串成一個連貫的工作流之後依然正確——批次規模不會讓分類判斷失準，跨筆記織連結不會因為批次而漏接，/new-adr 接在 /refine-inbox 之後也不會互相干擾或覆蓋彼此的異動。
👉 明天 Day20 起，我們要從「管理筆記」邁向「理解筆記之間的關係」，正式進入 Graphify 知識圖譜階段。我們明天見！
iThome鐵人賽
看影片追技術